The present invention relates to the field of writing data to and reading data from media storage devices. More particularly, the present invention relates to the field of writing both asynchronous and isochronous data to media storage devices and reading both asynchronous and isochronous data from media storage devices.
The IEEE 1394-1995 standard, xe2x80x9c1394 Standard For A High Performance Serial Bus,xe2x80x9d is an international standard for implementing an inexpensive high-speed serial bus architecture which supports both asynchronous and isochronous format data transfers. In addition, the IEEE 1394-1995 bus has a universal clock called the cycle timer. This clock is synchronized on all nodes. Isochronous data transfers are real-time transfers which take place based on the universal clock such that the time intervals between significant instances have the same duration at both the transmitting and receiving applications. Each packet of data transferred isochronously is transferred in its own time period. An example of an ideal application for the transfer of data isochronously would be from a video recorder to a television set. The video recorder records images and sounds and saves the data in discrete chunks or packets. The video recorder then transfers each packet, representing the image and sound recorded over a limited time period, during that time period, for display by the television set. The IEEE 1394-1995 standard bus architecture provides multiple independent channels for isochronous data transfer between applications. A six bit channel number is broadcast with the data to ensure reception by the appropriate application. This allows multiple applications to simultaneously transmit isochronous data across the bus structure. Asynchronous transfers are traditional reliable data transfer operations which take place as soon as arbitration is won and transfer a maximum amount of data from a source to a destination.
The IEEE 1394-1995 standard defines a high-speed serial bus for interconnecting digital devices thereby providing a universal I/O connection. The IEEE 1394-1995 standard defines a digital interface for the application thereby eliminating the need for an application to convert digital data to analog data before it is transmitted across the bus. Correspondingly, a receiving application will receive digital data from the bus, not analog data, and will therefore not be required to convert analog data to digital data. The cable required by the IEEE 1394-1995 standard is very thin in size compared to other bulkier cables used to connect such devices in other connection schemes. Devices can be added and removed from an IEEE 1394-1995 bus while the bus is operational. If a device is so added or removed the bus will then automatically reconfigure itself for transmitting data between the then existing nodes. A node is considered a logical entity with a unique address on the bus structure. Each node provides in a standard address space, an identification ROM, a standardized set of control registers and in addition, its own address space.
The IEEE 1394-1995 standard defines a protocol as illustrated in FIG. 1. This protocol includes a serial bus management block 10 coupled to a transaction layer 12, a link layer 14 and a physical layer 16. The physical layer 16 provides the electrical and mechanical connection between a device and the IEEE 1394-1995 cable. The physical layer 16 also provides arbitration to ensure that all devices coupled to the IEEE 1394-1995 bus have arbitrated access to the bus as well as actual data transmission and reception. The link layer 14 provides data packet delivery service for both asynchronous and isochronous data packet transport. This supports both asynchronous data transport, using an acknowledgement protocol, and isochronous data transport, providing an un-acknowledged real-time guaranteed bandwidth protocol for just-in-time data delivery. The transaction layer 12 supports the protocols necessary to complete asynchronous data transfers, including read, write and lock. The serial bus management block 10 contains an isochronous resource manager for managing the resources associated with isochronous data transfers. The serial bus management block 10 also provides overall configuration control of the serial bus in the form of optimizing arbitration timing, guarantee of adequate electrical power for all devices on the bus, assignment of the cycle master, and allocation of isochronous channel and bandwidth resources.
The AV/C Command Set is a command set used for transactions to and from consumer audio/video equipment over an IEEE 1394-1995 serial bus. This AV/C command set makes use of the Function Control Protocol (FCP) defined by IEC-61883, the ratified international standard for the transport of audio/video command requests and responses. AV/C commands are transmitted through AV/C transactions. An AV/C transaction consists of one AV/C command frame addressed to the target node""s FCP_Command register and zero or more AV/C response frames addressed to the requesting node""s FCP_Response register.
Each audio/video unit or subunit can implement a subset of the AV/C command set. An unsupported command received by an audio/video unit is rejected with a not implemented response. Support for the different commands is characterized as mandatory, recommended, optional and vendor-dependent. A mandatory command is supported by any audio/video device that claims compliance with the AV/C command set and that implements the audio/video unit or subunit type for which the command is defined. An AV/C compliant device is identified by an entry within its configuration read-only memory (ROM). A recommended command is optional for an AV/C compliant device, but represents a basic functionality, such as video and audio insert modes for a VCR subunit""s record command. If the device supports a unit or subunit type that has the functionality corresponding to the command, it is recommended that the command be implemented. An optional command is optional for an AV/C compliant device. Support for and interpretation of a vendor-dependent command are defined by the device vendor.
AV/C commands are grouped into four command types including control, status, inquiry and notify command types. A control command is sent by a controller to another audio/video device, the target, to instruct the target to perform an operation. A target that receives a control command will return an AV/C response frame including either a not implemented, accepted, rejected or interim response code. The target will return a not implemented response code when the target does not support the control command specified or the command is addressed to a subunit not implemented by the target. The target will return an accepted response code when the target implements the control command specified and the current state of the target permits execution of the command. The target will return a rejected response code when the target implements the control command specified but the current state of the target does not permit execution of the command. The target will return an interim response code if the control command specified is implemented by the target, but the target is unable to respond with either an accepted or rejected response code immediately. Unless a subsequent bus reset causes the AV/C transaction to be aborted, the target will ultimately return a response frame with an accepted or rejected response code after returning an interim response code.
A status command is sent by a controller to an audio/video device to request the current status of the target device. Status commands may be sent to either audio/video units or subunits. A target that receives a status command will return an AV/C response frame including either a not implemented, rejected, in transition or stable response code. A target will return a not implemented status response code when the target does not support the status command specified or the command is addressed to a subunit not implemented by the target. A target will return a rejected status response code when the target implements the status command specified but the target state does not permit the return of status for the command. The target will return an in transition status response code when the target implements the status command specified, but the current state of the target is in transition. The target will return a stable status response code when the target implements the status command specified and the information requested is reported in the values in the AV/C response frame.
An inquiry command is used by a controller to determine whether or not a target audio/video device supports a particular control command. A controller can reliably use inquiry commands to probe the capabilities of a target, since the target shall not modify any state nor initiate any command execution in response to an inquiry command. A target that receives an inquiry command will return an AV/C response frame including either an implemented or a not implemented response code. An implemented response code notifies the controlling node that the corresponding control command specified is implemented by the target audio/video device. A not implemented response code notifies the controlling node that the corresponding control command specified is not implemented by the target audio/video device.
A notify command is used by a controller to receive notification of future changes in an audio/video device""s state. Responses to a notify command will indicate the current state of the target and then, at some indeterminate time in the future, indicate the changed state of the target. A target that receives a notify command will return an immediate response frame including either a not implemented, rejected or interim response code. A target will return a not implemented response code when the target does not support the notify command specified or the command is addressed to a subunit not implemented by the target. A target will return a rejected response code when the target implements event notification for the condition specified but is not able to supply the requested information. A target will return an interim response code when the target supports the requested event notification and has accepted the notify command for any future change of state. The current state is indicated by the data returned in the response frame. At a future time, the target will then return an AV/C response frame with either a rejected or changed response code.
The AV/C Disk Subunit Enhancements For Hard Disk Drive Specification is a technical specification of the 1394 Trade Association which includes enhancements to the AV/C Command Set for managing the storage and retrieval of audio and video (AV) content to and from hard disk drive devices. Under this AV/C Disk Subunit specification, AV content is stored on a hard disk drive in an AV track. An AV track is defined as a sequence of recorded data and is described by an AV/C object entry. Each AV track is made up of a number of AV frames. An AV frame is a uniquely identifiable section of an AV track. An AV track can be separated into multiple sections called AV segments. AV segments are uniquely identifiable sections of an AV track and can be specified as parameters in AV commands. An AV packet is an accessing unit for an AV track.
A traditional hard disk drive records data received, over the IEEE 1394-1995 serial bus and plays it back over the IEEE 1394-1995 serial bus according to commands received from an external controller using a protocol such as the serial bus protocol 2 (SBP-2). The external controller is referred to as an initiator and provides command data structures to the hard disk drive referred to as a target which inform the hard disk drive where on the media the data is to be written, in the case of a write operation, or read from, in the case of a read operation. All initiator requests for actions by the target device are expressed within operation request blocks (ORBs) fetched by the target device using read transactions. Each ORB within the SBP-2 protocol has a format as illustrated in FIG. 2. The notify bit n advises the target device whether or not notification of completion of the operation is required. When the notify bit n has a value equal to xe2x80x9c0xe2x80x9d, the target device may elect to suppress completion notification except when there is an error. When the notify bit n has a value equal to xe2x80x9c1xe2x80x9d, the target device always stores a status block in the memory of the initiator device to notify the initiator of completion of the operation. The request format field rq_fmt specifies the format of the ORB. The following formats for the request format field rq_fmt are defined as illustrated below in Table I.
A request format field rq_fmt value of xe2x80x9c0xe2x80x9d indicates that the ORB has a format specified by the SBP-2 protocol. A request format field rq_fmt value of xe2x80x9c2xe2x80x9d indicates that the ORB has a format that is vendor dependent. A request format field rq_fmt value of xe2x80x9c3xe2x80x9d indicates that the ORB has a dummy request format. The request format field rq_fmt value of xe2x80x9c1xe2x80x9d is reserved for future standardization.
A management ORB is a 32-byte data structure having a format as illustrated in FIG. 3. For a management ORB, the notify bit n has a value of xe2x80x9c1xe2x80x9d and the request format field rq_fmt has a value of xe2x80x9c0xe2x80x9d. The function field within the management ORB specifies the management function requested, as defined by the functions listed below in Table II.
A function field value of xe2x80x9c0xe2x80x9d indicates that the ORB is requesting a login function. A function field value of xe2x80x9c1xe2x80x9d indicates that the ORB is requesting a query login function. A function field value of xe2x80x9c3xe2x80x9d indicates that the ORB is requesting a reconnect function. A function field value of xe2x80x9c4xe2x80x9d indicates that the ORB is requesting a set password function. A function field value of xe2x80x9c7xe2x80x9d indicates that the ORB is requesting a logout function. A function field hexadecimal value of xe2x80x9cBxe2x80x9d indicates that the ORB is requesting an abort task function. A function field hexadecimal value of xe2x80x9cCxe2x80x9d indicates that the ORB is requesting an abort task set function. A function field hexadecimal value of xe2x80x9cExe2x80x9d indicates that the ORB is requesting a logical unit reset function. A function field hexadecimal value of xe2x80x9cFxe2x80x9d indicates that the ORB is requesting a target reset function. The function field values of xe2x80x9c2xe2x80x9d, xe2x80x9c5-6xe2x80x9d, xe2x80x9c8-Axe2x80x9d and xe2x80x9cDxe2x80x9d are reserved for future standardization.
Within the management ORB, the status field status FIFO contains an address allocated for the return of status information generated by the management request. The remainder of the fields within the management ORB of FIG. 3 are function dependent.
Use of a media storage device, such as a hard disk drive, for storing streams of audio and video data is taught in U.S. patent application Ser. No. 09/022,926, filed on Feb. 12, 1998 and entitled xe2x80x9cMEDIA STORAGE DEVICE WITH EMBEDDED DATA FILTER FOR DYNAMICALLY PROCESSING DATA DURING READ AND WRITE OPERATIONS,xe2x80x9d which is hereby incorporated by reference. When storing audio and video data streams on such a hard disk drive, the available capacity of the device can be quickly utilized, due to the large amounts of data included in typical audio and video data streams. If multiple traditional hard disk drives are utilized to store large streams of data, then the user must typically be responsible for management of these storage and retrieval procedures. This storage management responsibility adds complexity to operations such as record and playback and requires the user to monitor and control storage and retrieval operations. An automatically configuring storage array which includes a plurality of media storage devices coupled together within a network of devices is taught in U.S. patent application Ser. No. 09/310,876, filed on May 12, 1999 and entitled xe2x80x9cAUTOMATICALLY CONFIGURING STORAGE ARRAY INCLUDING A PLURALITY OF MEDIA STORAGE DEVICES FOR STORING AND PROVIDING DATA WITHIN A NETWORK OF DEVICES,xe2x80x9d which is hereby incorporated by reference.
Currently, isochronous data recorded using the AV/C Command Set can only be read using the AV/C Command Set. Correspondingly, asynchronous data recorded using the SBP-2 protocol can only be read using the SBP-2 protocol. There is currently no media storage device which can capture data directly from an IEEE 1394-1995 enabled consumer device using the AV/C Command Set and the isochronous communications mechanism, then permit this captured data to be freely read or written using traditional personal computer protocols, such as the SBP-2 protocol. Furthermore, there is currently no media storage device which can capture data directly from a device using traditional personal computer protocols, such as the SBP-2 protocol, then permit this captured data to be freely read or written using the AV/C Command Set and the isochronous communications mechanism.
A multi-protocol media storage device operates according to both the AV/C Command Set and the FCP protocol to record and retrieve data in an isochronous format and the SBP-2 protocol to record and retrieve data in an asynchronous format. Isochronous data is recorded on the media storage device on AV tracks according to the AV/C Command Set. Asynchronous data is recorded on the media storage device in sections called asynchronous spaces. Additionally, isochronous data is recorded in a portion of an asynchronous space as described in one or more operation request blocks delivered according to the SBP-2 protocol. The AV tracks and the asynchronous spaces are each preferably numbered with a unique integer value. A management operation request block (ORB) includes a function field that can have a value indicating that the request is a manage asynchronous space request. Within a manage asynchronous space request a sub-function field indicates that the request is a create, delete or query asynchronous space request. Command ORBs having a request format field value of xe2x80x9c0xe2x80x9d are performed within the lowest numbered asynchronous space. Command ORBs having a request format field value of xe2x80x9c1xe2x80x9d are performed within an indicated asynchronous space. Previously recorded data within either an AV track or an asynchronous space can be accessed using both the FCP protocol and the SBP-2 protocol. Additionally, an initiator can provide an ORB to the target which describes a portion of an asynchronous space in the form of starting address and lengths of multiple discontinuous regions. In this form the target will either record to or play from these portions of the address space using an isochronous data transfer.
In one aspect of the present invention, a method of accessing a media storage device coupled to one or more devices includes the steps of receiving a command from one of the one or more devices, determining if the command is one of an isochronous format command and an asynchronous format command, accessing the media storage device in an asynchronous format if the command is an asynchronous format command and accessing the media storage device in an isochronous format if the command is an isochronous format command. The media storage device records data in the isochronous format in AV tracks and data in the asynchronous format in one or more asynchronous spaces. The isochronous format command is preferably an AV/C command according to FCP protocol. The asynchronous format command is preferably delivered according to SBP-2 protocol. The asynchronous format command includes an operation request block. The operation request block is associated with a scatter/gather list describing portions of asynchronous space on the media storage device to be read or written by isochronous data. The method further includes the step of creating an asynchronous space within the media storage device in response to receiving a manage asynchronous space request requesting creation of the asynchronous space. The method further includes the step of deleting a previously created asynchronous space within the media storage device in response to receiving a manage asynchronous space request requesting deletion of the previously created asynchronous space. The media storage device is preferably a hard disk drive. Communication between the media storage device and the one or more devices preferably substantially complies with a version of the IEEE 1394 standard.
In another aspect of the present invention, a media storage device for storing and retrieving data received from one or more devices in response to a command includes an interface circuit configured to couple to the one or more devices to communicate with the one or more devices, a control circuit coupled to the interface circuit to determine if the command is one of an isochronous format command and an asynchronous format command and media coupled to the control circuit to record isochronous data received from the one or more devices in an AV track in response to an isochronous record command, to record asynchronous data received from the one or more devices in an asynchronous space in response to an asynchronous write command and to retrieve both previously recorded asynchronous data and isochronous data. Preferably, the isochronous format command is an AV/C command according to FCP protocol. Preferably, the asynchronous format command is delivered according to SBP-2 protocol. An asynchronous space is created on the media in response to a manage asynchronous space request requesting creation of the asynchronous space received from one of the one or more devices. The media storage device is preferably a hard disk drive. The interface circuit is preferably coupled to the one or more devices through a network which substantially complies with a version of the IEEE 1394 standard.
In yet another aspect of the present invention, a management operation request block for requesting a manage asynchronous space operation within a media storage device includes a function field including a first value indicating that the operation request block is a manage asynchronous space operation request block and a sub-function field including a second value indicating a type of manage asynchronous space request requested in the management operation request block. The type of manage asynchronous space request is a selective one of a create asynchronous space request, a delete asynchronous space request and a query asynchronous space request. An asynchronous space is created on the media storage device in response to a manage asynchronous space request of the type create asynchronous space. An existing asynchronous space is deleted on the media storage device in response to a manage asynchronous space request of the type delete asynchronous space. Information about existing asynchronous spaces on the media storage device is obtained in response to a manage asynchronous space request of the type query asynchronous space. The management operation request block further includes a notify bit and a request format field. The management operation request block preferably has a format which substantially complies with SBP-2 protocol. The media storage device is preferably a hard disk drive.
In still yet another aspect of the present invention, a method of accessing a media storage device coupled to one or more devices within a network of devices includes the steps of receiving a command from one of the one or more devices, determining if the command is one of an isochronous AV/C format command according to FCP protocol and an asynchronous format command received according to SBP-2 protocol, accessing the media storage device in an asynchronous format according to the SBP-2 protocol if the command is an asynchronous format command and accessing the media storage device in an isochronous format according to the FCP protocol if the command is an isochronous format command. The method further includes the step of storing isochronous data in response to a record isochronous format command within an AV track in the media storage device. The method further includes the step of creating an asynchronous space within the media storage device in response to receiving a manage asynchronous space request requesting creation of the asynchronous space. The method further includes the step of storing asynchronous data in response to a write asynchronous format command within the asynchronous space. The method further includes the step of deleting an existing asynchronous space within the media storage device in response to receiving a manage asynchronous space request requesting deletion of the existing asynchronous space. The method further includes the steps of determining if the command is one of an isochronous format command received according to a modified SBP-2 protocol and accessing the media storage device in an isochronous format if the command is received according to the modified SBP-2 protocol and requests isochronous handling. The method further includes the step of storing isochronous data in response to a command received according to the modified SBP-2 protocol. The media storage device is preferably a hard disk drive. Communication between the network of devices preferably substantially complies with a version of the IEEE 1394 standard.
In yet another aspect of the present invention a network of devices includes one or more content devices for generating and consuming content data and a media storage device coupled to the one or more content devices for storing and retrieving the content data in response to a command, including an interface circuit coupled to the one or more content devices to transmit communications to and receive communications from the one or more content devices, a control circuit coupled to the interface circuit to determine if the command is one of an isochronous format command and an asynchronous format command and media coupled to the control circuit to record isochronous data received from the one or more content devices in an AV track in response to an isochronous record command, to record asynchronous data received from the one or more content devices in an asynchronous space in response to an asynchronous write command and to retrieve both recorded asynchronous data and isochronous data. The network of device further includes a controller coupled to the interface circuit and to the one or more content devices for generating the command and transmitting the command to the interface circuit. The command can also be received from one of the one or more content devices. The isochronous format command is preferably an AV/C command according to FCP protocol. The asynchronous format command is preferably delivered according to SBP-2 protocol. An asynchronous space is created on the media in response to a manage asynchronous space request requesting creation of the asynchronous space received from one of the one or more content devices. The media storage device is preferably a hard disk drive. The interface circuit is preferably coupled to the one or more content devices through a network which substantially complies with a version of the IEEE 1394 standard.